崩溃机制
当NW.js崩溃时 , 将在桌面创建名为minidump
(.dmp
)文件 . 该文件中包括问题报告信息 , 通过解码minidump
文件获取崩溃时的异常信息 . 这样能够查找到NW.js崩溃的原因 .
minidump
文件中提取出的异常信息过程 , 需要利用三个条件: 崩溃时产生的minidump(.dmp
)文件 , NW.js的符文件以及minidump_stackwalk
工具 .
获取minidump文件
NW.js崩溃时在不同系统中生成minidump的路径:
- Linux:
~/.config/<name-in-manifest>/Crash\ Reports/
- Windows:
%LOCALAPPDATA%\CrashPad
- Mac:
~/Library/Application\ Support/<name-in-manifest>/CrashPad/
<name-in=manifest>
为配置文件中name
属性 .
注 , Linux系统中生成的minidump文件会附带头文本信息 , 该部分信息在解码之前需要删除 , 真正minidump文件内容由`MDMP`开始 , 之前的内容是不可读的 , 可以直接删除 .
整理条码文件
NW.js释放包中的条码文件在NW.js下载目录的同名目录中 . 条码文件(.sym)能够从下载包中提取 .
整理条码文件需要使用minidump_stackwalk
工具在正确的路径中与正确的文件名进行 . minidump_stackwalk
使用简单条码供应商获取条码文件 . 以下步骤展示如何查找条码文件 .
工具将以下模式尝试查找.sym
文件:
{SYMBOLS_ROOT}/{DEBUG_FILE_NAME}/{DEBUG_IDENTIFIER}/{DEBUG_FILE_NAME_WITHOUT_PDB}.sym
{SYMBOLS_ROOT}
是所有条码文件的根目录 . NW.js所有版本或者使用系统都可以将.sym
文件放入该目录中 .{DEBUG_FILE_NAME}
,{DEBUG_IDENTIFIER}
和{DEBUG_FILE_NAME_WITHOUT_PDB}
作为.sym
文件的第一行 , 例如MODULE Linux x86_64 265BDB6BE043D5C70D3A1E279A8F0B1A0 nw
265BDB6BE043D5C70D3A1E279A8F0B1A0
对应{DEBUG_IDENTIFIER}
nw
对应{DEBUG_FILE_NAME}
.{DEBUG_FILE_NAME_WITHOUT_PDB}
能够覆盖删除.pdb
的{DEBUG_FILE_NAME}
, 该方式只有在Windows系统中需要 .
Minidump解码
minidump_stackwalk
能够使用NW.js构建 . Linux和Mac系统的报告器代码中直接构建 . Windows系统中使用Cygwin预制构建 .
运行以下命令从minidump
获取异常信息:
minidump_stackwalk minidump_file.dmp /path/to/symbols_root 2>&1
如果条目文件不能正确整理 , 仍然可以使用该工具获取 . 但不能查看 , 最后部分会输出一下警告信息:
0x00240000 - 0x02b29fff nw.exe ??? (main) (WARNING: No symbols, nw.exe.pdb, 669008F7B6EE44058CBD5F21BEB5B5CFe)
触发崩溃以测试
测试崩溃机制特性 , NW.js提供APIs触发崩溃: App.crashBrowser()
和App.crashRenderer()
. 分别是崩溃浏览器进程和渲染进程 .
参考
- http://www.chromium.org/developers/decoding-crash-dumps
- http://code.google.com/p/google-breakpad/wiki/GettingStartedWithBreakpad